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Reconfiguration of a 
Group of Network Nodes 
in an Ad~hoc Netwrk 



FIELD OF INVENTION . 

The present invention relates to a reconfiguration of a group 
of network nodes in an ad-hoc network, and in particular to a 
reconfiguration of a group of network nodes in an ad-hoc 
network with particular emphasis on reconfiguration 
consistency. 

BACKGROUND ART 

In WO 01/14968 Al there is described a fieldbus upgradable 
apparatus and method, wherein control devices residing on a 
fieldbus communications network . are modified without 
interrupting the operation of the control devices in a 
seamless manner. . 

In US-A-6, 113/ 652 there is described a communication network 
equipment capable of non-disruptive software upgrade which is 
used in a telecommunications network having a plurality of 



coupled nodes and a network controller coupled to at least 
one of these nodes . 



Further, in US-6.141,683 A there is described a method for 
remotely and reliably updating the software on a computer 
with provision for roll-back with particular focus on ' 
integrity between different software versions. 

Further, in US-A-5, 699, 275 there is described a system and 
method for remote patching of operating code located in a 
mobile unit, wherein a manager host is operable to initiate 
transmission through a communication network of at least 
one discrete patch message defining at least one patch. 

Further, in US-2001/0029178 Al there is described a 
wireless software update with version control in a wireless 
communication system having a system backbone, having a 
host computer coupled to the system backbone, at least one 
base station coupled to the system backbone, and a 
plurality of mobile devices within the system. 

Further, in WO 01/84792 Al there is described a method and 
gateway for performing an online switching of software in a 
communication system. 

Overall, numerous NumorouQ factors associated with 
technology, business, regulation and social behavior have 
driven the spreading of wireless ad-hoc networking in the 
past, i.e., a wireless network fomed without any central 
administration. Ad-hoc networks consist of a plurality of 
mobile devices using a wireless interface for exchange of 



packet data. As each mobile device in the ad-hoc network 
serves as router and host, each such mobile device will 
forward data packets on behalf of other mobile devices and 
further run user applications. Therefore, in ad-hoc 
networks, mobile devices are connected directly for local 
cooperation. 

To support on-going improvement of functionality, an ad-hoc 
notvjorlc networks should provide the opportunity for a 
software update. It is often required that all mobile 
devices in such an ad-hoc network have the same software 
version, e.g., for reasons of compatibility. For this 
reason, the software update should take place in a 
coordinated manner, preferably at the same point in time. 
In addition, either all mobile devices reconfigure 
successfully, or they all fall back to the software version 
before installation. 



However, up to now^ no appropriate approach to the 
coordinated update of software in ad-hoc networks is 
available. Another issue not addressed so far is that 
during reconfiguration^ mobile devices may not communicate 
properly. 



SUMMARY. OF INVENTION 



In view of the above, the object of the present invention 
is to provide a solution to consistent software 
reconfiguration in ad-hoc networks. 
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According to the present invention, this object is achieved 
through a method of reconfiguration for a network node, 
e.g., a mobile device or a stationary device, in an ad-hoc 
network. The method comprises a first step of preparing a 
5 transition from an initial software configuration to a 
target software configuration and a second step to deciding 
on commitment to the target software configuration. 
According to the present invention^ the decision on 
commitment is taken in view of a result of reconfiguration 
10 indicated through at least one further network node in the 
ad-hoc networ k, in particular when every result of 
configuration received at the network node from a reachable 
further network node is evaluated to be positive , 

15 Therefore, according to the present invention, a transition 
from an initial software configuration to a target software 
configuration is not executed anyway but such a transition 
is taken on the basis of information being related to 
reconfiguration at network nodes being reachable from the 

20 network node deciding on commitment to the target software 
configuration. 

In particular, if the information received is related to 
further reconfiguration processes in the further network 
25 nodes, it is possible to allow for coordination of 
reconfiguration between different network nodes, although 
each single network node is operating autonomously. 

In other words, according to the present invention^ it is 
30 proposed to not simply initiate an update process for 
different network nodes in an ad-hoc network and to just 



hope that the reconfiguration will be successful, but to 
use feedback mechanisms locally in each single network node 
to decide on commitment to target software configurations. 

According to a preferred embodiment of the invention it is 
proposed to negotiate a maximum reconfiguration' time period 
between at least two network nodes executing 
reconfiguration. The maximum reconfiguration time is the 
maximum time for reconf iguration, indication of 
reconfiguration result, and executing a fallback to the 
initial software configuration for network nodes in the ad- 
hoc network participating in the reconfiguration process. 

Further, preferably, a start of reconfiguration is 
coordinated between at least two network nodes in the ad- 
hoc network executing a reconfiguration process . 
Optionally, one network node in the ad-hoc network may 
organize the negotiation process. 

The negotiation of a maximum time for reconfiguration and 
the "synchronization" or coordination of start of 
reconfiguration are of particular relevance for achieving a 
simple, but nevertheless highly efficient framework of 
autonomous reconfiguration in each network node. 

The negotiation process of a maximum reconfiguration time 
period is adapted to a heterogeneous update of software 
within different network nodes, as the maximum time period 
for reconfiguration will be set according to the target 
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software configuration in thcnctv^ork — the network node 
requiring the longest time period for reconfiguration. 

Yet another advantage is that a time period during which 
5 services are interrupted due to reconfiguration at the 
different network nodes is foreseeable and minimized. If 
after expiry of the negotiated maximum time period no 
definitive reconfiguration success is established in the 
ad-hoc network, immediately counter-measures may be taken 
10 to bring the ad-hoc network back to operation on the basis 
of the initial software configuration before start of the 
reconfiguration process. 

According to a further preferred embodiment of the 
15 invention, it is proposed to determine which network nodes 
are reachable after the reconfiguration process. 

This preferred embodiment of the present invention is 
provided to control two different reconfiguration 
20 scenarios. 

A first scenario would be that reconfiguration is not 
related to communication software - e.g., like speech-codec 
software - but to some type of application. Therefore, 
25 during reconfiguration communication is still possible. In 
such a case, connectivity from the network node executing 
the reconfiguration process to further network nodes 
running the reconfiguration process is not an issue. 



30 



A second scenario would be that some type of communication- 
related software is reconfigured so that .it may not be 
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guaranteed that the ad-hoc network topology remains 
unchanged during the course of reconfiguration. One example 
would be a communication software update failure at a 
specific network node which leaves the ad-hoc network as it 
5 may no longer communicate with those network nodes which 
successfully reconfigured communication software. 
Therefore, excluding this network node from the commitment 
decision - after determination of reachability - allows to 
avoid over-restrictive commitment decisions and a related 
10 decrease in functionality improvement. 

Further preferred embodiments of the present invention 
relate to the decision mechanisms underlying the commitment 
to a new software configuration in a network node. 

15 

One option is to commit to the target software when every 
result of reconfiguration received at the network node is 
positive. This type of commitment achieves maximtim 
consistency of software versions after reconfiguration as 
20 only a fully successful reconfiguration process at 
different network nodes allows for transfer to the target 
software configuration in each single network node. 

A further option relates to the other extreme case where no 
25 information regarding the outcome of reconfiguration at 
other network nodes is received at all. In this case - 
after expiry of the maximum reconfiguration time period - 
it is proposed to execute a fallback to the initial 
software configuration. The rationale behind this approach 
30 is that, initially, communication was possible on the basis 
of the initial software configuration. Further, the fact 
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that no reconfiguration result was received at the network 
node deciding on the commitment to the new software 
configuration is an indication that communication on the 
basis of the newly installed software is not possible. 
5 Therefore, fallback to the initial software configuration 
is the optimal way to re-establish connectivity in the ad- 
hoc network.. . 

Yet another option is to execute a fallback to initial 
10 software configuration, when at least one negative 
reconfiguration result was reported to the network node 
deciding on commitment to the target software 
configuration. The rationale behind this commitment 
decision is to maximize connectivity and communication 
15 capability. Assuming that only a single mobile network node 
could leave the ad-hoc network according to the negative 
xeconfiguration result, it is wise to continue the 
operation on the basis of the initial software 
configuration to maintain maximum connectivity. 

20 

Further, preferred embodiments of the present invention 
relate to the involvement of a network node into the 
exchange of reconfiguration results. 

25 According to a preferred embodiment of the present 
invention, each network node either sends a positive or 
negative indication of reconfiguration, according to the 
outcome of the transition from the initial software 
configuration to the target software configuration. 



It should be noted that the exchange of reconfiguration 
results may be achieved in various ways. 



A first way would be to indicate the reconfiguration result 
through dedicated positive or negative signals. Preferably, 
these signals may be processed, both, by through the 
initial software configuration and the target software 
configuration. 

A second way would be to indicate a positive 
reconfiguration, e.g., of communication software, 
implicitly through automatic set-up of network 
connectivity - 

For both alternatives given above, the exchange of 
reconfiguration results may be executed repeatedly to 
Improve penetration of reconfiguration results in the ad- 
hoc network. 

A further preferred embodiment of the present invention 
relates to the determination of network nodes in the ad-hoc 
network participating in the reconfiguration process. 

According to the present invention, it is proposed to use a 
plurality of criteria for such determination which may be 
used either alone or in combination. 

A first such criterion is communication capability of a 
network node. Here, it is proposed to have a match between 
the target software configuration and the related 
communication capabilities of a network node . In other 
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words, it would be meaningless to install communication 
software at a network node which is not applicable in view 
of the hardware support given by the network node. Further, 
communication capability may also be understood in the 
5 sense that only those network nodes are considered during 
software reconfiguration which support a specific style of 
communication. A further criterion is network connectivity, 
. which means that network nodes not being reachable in the 
ad-hoc network are per se excluded from the reconfiguration 
10 process. 

Yet another criterion may be profile data for a further 
detailed specification of the network node or its end user. 
Such profile data may classify whether a network node 
15 supports specific types of services which form part of the 
reconfiguration process. Using such profile data it is 
■possible to avoid unnecessary retrieval of software and 
related data traffic in the ad-hoc network. 

20 Yet another criterion is a movement pattern of a movable 
network " node, i.e. a mobile device, which may either be 
predicted or be known per se. Assuming that - in view of 
the movement pattern - a mobile device will soon leave the 
ad-hoc network, it is highly meaningful to avoid 

25 unnecessary data traffic to .such a mobile device for 
reconfiguration with respect to services being of 
importance only within the established ad-hoc network . 

Yet another criterion that might be used as basis for 
30 determining network nodes participating in the 
reconfiguration in an ad-hoc network is a status of a 
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network node, typically a hardware status. One such example 
would be the energy that is available within a network 
node, which is of particular relevance for mobile devices. 
Here, when the . amount of energy is not sufficient to 
support a complete reconfiguration process, it is 
reasonable to exclude the network node from the 
reconfiguration process to avoid any. disturbance of 
reconfiguration for the remaining network nodes in the ad- 
hoc network. Another example of a hardware status may be 
the type of standard being supported for circuit-switched 
or packet-switched communication through the network node 
or processing power provided- through processor devices in 
the network node. The reconfiguration of services only 
makes sense when a network node offers a certain processing 
15 power required for certain services. 

-Yet another example of a criterion to determine which 
network nodes should be reconfigured could be a group 
membership of a network node, which group membership may be 
specified in advance. This criterion is of particular value 
for supporting different user groups or closed user groups, 
e.g.., in police departments or hospitals. Another grouping 
may be according to companies,, membership to specific 
organizations, profession of end user, etc. 



20 



25 



30 



Yet another criterion for determination of network nodes 
participating in a reconfiguration could be a priority 
assigned to the end user of a network node. This criterion 
facilitates the ranking of end users, which is of benefit 
for providers of commercial services aiming at user 
selectivity. 
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It should be noted that the determination of network nodes 
as outlined above could either be executed before start of 
reconfiguration or be repeated during the reconfiguration 
process. The latter option allows to identify additional 
network nodes dropping out of the reconfiguration process, 
and therefore to minimize traffic in the ad-hoc network and 
to accelerate the reconfiguration process. 

Another preferred embodiment of the present invention 
relates to retrieval of software for executing the 
transition from the initial software configuration to the 
target software configuration. 

According to a preferred embodiment, software may be 
retrieved locally from a portable electronic device, e.g., 
a smart card or any other type of portable device that 
allows transfer of the related data. 

Yet another option is to retrieve software via a mobile 
communication environment of any type, e.g., from the 
Internet via a personal area network, a wireless local area 
network, a wireless infrared communication network, 
Bluetooth communication, or any other suitable type of 
mobile communication environment. 

Further preferred embodiments of the present invention 
relate to the type of software which is installed for 
reconfiguration . 
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As should be understood from the above, the present 
invention is not restricted to any type of software. The 
present invention may be used to reconfigure application 
software, communication software, operating system 
software, firmware, etc. 

Further, the inventive reconfiguration process is not only 
related to software as such, but also to related control 
parameters. Therefore, one might imagine a situation where 
the software as such remains unchanged and only the 
parameter controlling the operation of the software are 
reconfigured in the sense outlined above. 

According to the present invention, also heterogeneous 
software reconfiguration using network node specific 
software for transition to. the target software 
configuration is fully supported. Therefore, the present 
invention is perfectly suited to support software 
reconfiguration with utmost flexibility and user specific 
adaptation. 

According to another preferred embodiment of the present 
invention there is provided a computer program product 
directly loadable into the internal memory of a network 
node of an ad-hoc network comprising software code portions 
for performing the inventive reconfiguration process when 
the product is run on a processor of the network node. 

Therefore, the present invention is also provided to 
achieve an implementation of the inventive method steps on 
computer or processor systems. In conclusion, such 



implementation leads to the provision of computer program 
products for use with a computer system or more 
specifically a processor comprised in, e.g., a mobile 
device like a mobile telephone, a laptop computer, or a 
PDA. 

These programs defining the functions of the present 
invention can be delivered to a computer/processor in many 
forms, including, but not limited to information 
permanently stored on non-writable storage media, e.g., 
read only memory devices such as ROM or CD ROM discs 
readable by processors or computer I/O attachments; 
information stored on .writable storage media, i.e. floppy 
discs and harddrives; or information convey to a 
computer /processor through communication media such as 
network and/pr Internet and/or telephone networks via 
modems or other interface devices. It should be understood 
that such media, when carrying processor readable 
instructions implementing the inventive concept represent 
alternate embodiments of the present invention. 

BRIEF DESCRIPTION OF DRAWING 

The best mode of carrying out the invention as well as 
preferred embodiments and examples will be explained with 
reference to the drawing, in which: 

^^9- i shows a network topology of an ad-hoc 
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. network to which the reconfiguration process 
according to the present invention is 
applicable; 

^^9- 2 shows a schematic diagram of a network node 

according to the present invention; 

3 shows a flowchart of operation for the 

network node shown in Fig. 2; 

^^9- 4 shows a schematic diagram of the software- 

reconfiguration unit shown in Fig. 2; 

^^9- 5 shows a flowchart of operation for different 

sub-units in the software reconfiguration 
unit shown in Fig. 4; 

^^9- 6 shows a flowchart of operation for the 

reconfiguration commitment unit shown in 
Fig. 2; 

^^9- shows a first example of the reconfiguration 

process according to the present invention; 
and 

^^9- 8 shows a second example of the 

reconfiguration process according to the 
present invention. 



DESCRIPTION OF BEST MODE AND PREFERRED EMBODIMENTS 
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In the following, the best mode of carrying out the present 
invention and preferred embodiments thereof will be 
explained with respect to the drawing. Throughout the ' 
specification, those parts being identical will be referred 
to using the same reference nximerals. 

Fig. 1 shows a network topology of an ad-hoc network to 
which the reconfiguration process according to the present 
invention is applicable. As outlined above, an ad-hoc 
network is a network formed without any central 
administration and consisting of network nodes, e.g., 
mobile devices or stationary devices, that use wireless 
interfaces to exchange circuit- or packet-switched data. It 
should be understood that there is not imposed any 
restriction either on the type. of network node nor on the 
type of communication in the ad-hoc network according to 
the present invention. 

Examples of network nodes are mobile devices like mobile 
telephones, PDAs, mp3-players, laptop computers, etc. or 
stationary devies like personal computers. Further, the 
type of ad-hoc networking may be suitably selected, e.g., 
on the basis of Bluetooth, HiperLAN/2, personal area 
network PAN, IEEE 802.11, WLL Multi-hop Access Systems, 
according to the MANET initiative taken by. the Internet 
Engineering Task Force IETF. 

The same also applies when the ad-hoc network is combined 
with a mobile cellular communication environment being 



17 



operated on the basis of, e.g., GSM, PDC, GPRS, UMTS, 
IMT2000, PHS, IS-95, or any hybrid combination thereof. 

Still further, it should be noted that the reconfiguration 
5 process explained in the following is suitable for any type 
of software, such as application software, conumunication 
software, firmware, operation system software, and/or 
related control parameters. 

10 Typical examples - without any binding effect on the 

present invention - would be mobile Internet application, 
. mobile multi-media application, personalized service 
application, global mobility support, or any other type of 
video, still image, audio data, text data, or speech-based 

15 application supporting software. 

^Further, communication-related software may be related, 
e.g., to speech coding, source coding, channel coding, 
radio control according to any standard like WCDMA, TDMA, 

20 FDMA, etc. Further, communication software may be related 
to any ad-hoc network routing protocol, e.g., a distance 
vector routing protocol DSVD, an ad-hoc on-demand distance 
vector routing protocol AODV, and/or a dynamic source 
routing protocol. Still further, examples of firmware could 

25 be a software which is necessairy to run a signal processing 
unit, e.g., a DSP, which is usually available within a 
mobile device . 



30 



Fig. 2 shows a schematic diagram of a network node 
according to the present invention. 
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As shown in Fig. 2, the network node 10 comprises a 
software reconfiguration unit 12 and a reconfiguration 
commitment unit 14. Further, for exchange of data in the 
ad-hoc network there is provided a communication unit 16, 
and a memory unit 18 allows the storage of any data 
involved with the operation of the network node 10. 

Fig. 3 shows a flowchart of operation for the network node 
10 shown in Fig. 2. Operatively, in a step SIO, the 
transition from an initial software configuration to a 
target software configuration is prepared, and in a step 
S12 there is taken a decision to commit to the new software 
configuration in view of a related * reconfiguration result 
indicated through at least one further network node of the 
ad-hoc network. 

:^Generally, the reconfiguration process is therefore split 
into two phases, a first one to prepare reconfiguration, 
and a second one to evaluate the reconfiguration result, to 
decide on commitment in the new software configuration, and 
finally to actually commit to the new software or to fall 
back to the initial software configuration. In the 
following, further aspects underlying this basis concept of 
a two-phase reconfiguration process will be discussed in 
more detail. 

Therefore, according to the present invention there is 
proposed a network node and method of reconfiguration 
thereof that ensure consistent software update. This means 
that all network nodes have the same consistent software 
version . 
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Within the general framework for a reconfiguration process 
as outlined above with respect to Figs. 2 and 3, the 
present invention may be varied in a plurality of ways, as 
5 will be outlined in the following. 

According to the present invention it is also proposed to 
determine network nodes in the ad-hoc network executing the 
reconfiguration at the start of reconfiguration. This is 

10 achieved on the basis of at least one criterion: 
communication capability of a network node; node 
connectivity; profile data of network node; movement 
pattern for a mobile network node, i.e. mobile device; 
hardware status of network node; priority of network node; 

15 and/or group membership of network node. 

Communication capability may be related to any specific 
type of communication - i.e.^ circuit-switched or packet- 
switched. Here, one might consider an application scenario 
20 where software being related to packet-switched 

communication is exchanged only, so that circuit-switched 
functionality remains unaffected. Therefore, network ndoes 
supporting circuit-switched communication only are not 
affected by the reconfiguration. 

25 

In addition, network connectivity in the sense of the 
present invention implies that only network nodes being 
integrated into the ad-hoc network should be considered for 
reconfiguration. Optionally, profile data of network nodes 
30 is integrated into the decision of whether- a network node 
will be reconfigured or not, which profile data may 
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describe the type of applications, type of communication 
services^ user preferences, etc. 

Still further, the movement pattern as criterion for 
reconfiguration allows to drop out those mobile network 
nodes from the reconfiguration process which are. in the 
process of leaving the ad-hoc network anyway. Therefore, an 
update of such a mobile network node, with respect to 
specific services in the current ad-hoc network becomes 
obsolete and should be avoided. 

Still further, hardware status of the network node is 
related both to a dynamic hardware status or a static 
hardware status, A first example for a dynamic hardware 
status is the energy being available within the network 
node, e.g., the load state of a mobile device battery. Only 
if enough energy is available within the network node, the 
reconfiguration of such a network node is meaningful. 
Further, only if enough memory for a specific type of 
application software is available within the network node - 
as example for a static hardware status - the network node 
should be reconfigured accordingly. 

Still further, additional criteria for determination of 
reconfiguration are priority of a network node and group 
membership. Here, priority assignment to a network node 
allows to exclude specific network nodes from 
reconfiguration and to have end users receiving privileged 
services. Group membership allows to set up different 
groups of network nodes and related end users forming ad- 
hoc networks and to support organizational aspects . 



A further aspect of preparation of a transition from an 
initial software configuration to a target software 
configuration is related retrieval of software. 

One option supported by the present invention is to 
download software to one network node being reachable In 
the ad-hoc network, and then to distribute* the software to 
each network node participating in the. reconfiguration. 

Remote retrieval of software - e.g., from the Internet - ' 
may be achieved via any type of mobile communication 
environment, e.g.,' a mobile communication network, a 
wireless local area network, a personal area network, 
wireless infrared communication, and Bluetooth 
communication. Mobile communication may be executed 
according to any type of standard, i.e., IMT2000, GSM, PDC, 
PHS, IS-95. 

According to the present invention, the reconfiguration 
supports also heterogeneous software update for different 
network nodes or, in other words, software reconfiguration 
may be achieved in a network node specific way. A further 
option would be to distribute software reconfiguration to 
at least two network nodes before subsequent distribution 
within the ad-hoc network. 

Yet another option for retrieving of software for 
reconfiguration would be to use a portable electronic 
device IC/USIM in a local manner, such that the software 
necessary for reconfiguration is. locally retrieved at 
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eachnetwork node. A modification of this approach would be 
that the portable electronic device is not only carrying 
software for a specific network node, but for a plurality 
of network nodes, and that the network node accommodating 
5 the portable electronic device is used for distribution of 
the software to further network nodes. 

Besides software retrieval via a mobile communication 
environment or a portable electronic device, a further 
10 option would be that software necessary for reconfiguration 
is already pre-installed at a network node and therefore is 
only to be activated to achieve reconfiguration. 

While above for selection of network nodes criteria and 
15 software retrieval mechanisms have explained as important 

aspects of the first step SIO to prepare a transition from 
..an initial software configuration to a target software 

configuration, in the following, important aspects of the 

decision on commitment to a new software configuration 
20 according to step S12 shown in Fig. 3 will be explained. 

The present invention relies on the understanding that the 
reconfiguration to the target software as such is not 
enough to provide consistency of functionality of network 

25 nodes after reconfiguration. Therefore, in addition to the 
step of software update as first phase of reconfiguration 
there is provided a second phase for evaluation of the 
reconfiguration result (s). The evaluation is a prerequisite 
to decide on commitment to the target software 

30 configuration, and for actual transfer to the new software • 
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configuration or establishment of a fallback process in 
view of the decision result. 

In other words, only if a successful reconfiguration is 
notified within a negotiable maximum time for 
reconfiguration -indication of- reconfiguration result, and 
executing a fallback to the initial software configuration 

- through different network nodes participating in the 
reconfiguration process, there will be achieved commitment 
to target software configuration (s) . Otherwise, there will 
be initiated a fallback to the starting point of 
reconfiguration to re-establish communication also when, the 
reconfiguration was not successful- This fallback mechanism 
allows to maintain operability of the different network 
nodes in the latter case. 

Further, the achievement of a reconfiguration process over 
different network nodes without central control is achieved 
through exchange of indication of reconfiguration results 
between network nodes in the ad-hoc network as will be 
explained in more detail in the following. 

When communication is interrupted during preparation of 
transition to the target software configuration a first 
option is to await the installation of the target software 
configuration and to then use the new communication 
software for configuration result indication. Alternatively 

- i.e., when reconfiguration is not successful - a fallback 
to the initial software configuration could be executed 
after the time period reserved for reconfiguration, and 
then the previous initial software configuration and 
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related coininunication software may be used for 
reconfiguration result indication. 

From the viewpoint of mobile device operating autonomously, 
5 any mismatch between the communication software after 
reconfiguration will be an indication to non-successful 
reconfiguration. To the contrary, a suitable exchange of 
data also after reconfiguration may be considered as 
implicit indication of successful reconfiguration without 
10 exchange of related dedicated signaling messages. 

Further communication may also continue during the 
reconfiguration process, typically when no communication 
software is involved in the reconfiguration process. Here, 

15 the indication of reconfiguration results is easier and may 
be executed immediately after termination of the 
preparation phase at each network node. Therefore, at the 
end of the time period being available for configuration 
preparation, the decision of commitment to the new software 

20 configuration and/or fallback to the initial software 
configuration may be taken without any delay. 

Optionally, the decision may be taken already before end of 
the maximum reconfiguration time period when positive 
25 reconfiguration indications are received from all involved 
network nodes before end of the maximum reconfiguration 
time period. 

According to yet another case, a network node may not 
30 receive any indication of a reconfiguration result at all, 
irrespective of whether communication is interrupted during 
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the reconfiguration process or continuously available- In 
that case, where a network node is completely "blind", the 
appropriate way is to execute fallback to initial software 
configuration of the network node before continuation of 
5 operation for this network node. 

While above general aspects of the present invention * have 
been explained with respect to Figs. 2 and 3, further 
details thereof will be explained with reference to Figs. 4 
10 to 6, respectively. 

Fig. 4 shows a schematic diagram of the software 
reconfiguration unit shown in Fig. 2. 

15 As shown in Fig. 4> the software reconfiguration unit 12 
comprises an ad-hoc network determination unit 20, a 
software retrieval unit 22, a negotiation unit 24, a 
coordination unit 26, and a timer unit 28, respectively. 

20 Fig. 5 shows a flowchart of operation of the different sub- 
units of the software reconfiguration unit 12 as shown in 
Fig. 4. The steps shown in Fig. 5 are basically related to 
the time period reserved for preparing the transition from 
the initial software configuration to the target software 

25 configuration. 

As shown in Fig. 5, at the beginning of this time period, 
the ad-hoc network determination unit 20 may determine 
network nodes in the ad-hoc network which execute a 
30 reconfiguration process in step S20 as outlined above. 
Then, in a step S22 the software retrieval unit will 



retrieve software according to the target software 
configuration as outlined above, and optionally also 
retrieve related software control parameters, e.g., 
parameters controlling the operation system of a network 
node. 

In a step S24, the negotiation unit may negotiate a maximum 
reconfiguration time period for the network nodes 
participating in the reconfiguration process. It should be 
noted that the maximum reconfiguration time period covers 
the time period provided for preparation of a transition to 
the target software state and, optionally a time period for 
evaluation of reconfiguration results, deciding on 
commitment on the target software configuration and 
executing the commitment or a fallback to the initial 
software configuration according to the determination 
result. 

Then, in a step S26, the coordination unit 28 may 
coordinate start of reconfiguration, when several network 
nodes execute reconfiguration such that different network 
nodes execute reconfiguration over the same time period or, 
in other words, in a coordinated and/or synchronized way. 
This is supported through provision of a timer unit 28 
which operatively starts a reconfiguration timer to measure 
the actual reconfiguration time against the negotiated 
maximum reconfiguration time in step S28. 

As shown in Fig, 5, a further step S30 - executed by the 
software retrieval and transition unit 22 ~ achieves • 
execution of transition to the new software configuration. 



step S30 divides into the sub-steps installation of new 
software, indication of success of installation, and 
forwarding of received reconfiguration results. It should 
be noted that this transition is achieved autonomously in 
each single network node and that the coordination is 
achieved through the reception and forwarding of 
reconfiguration results from further network node. 

While each network node is operating autonomously, it is 
the continuous reception and forwarding of reconfiguration- 
related information that allows to distribute 
reconfiguration status information in the ad-hoc network, 
which then may again be processed autonomously in each 
mobile device under the ad-hoc networking paradigm. 

As shown in Fig. 5, the ad-hoc determination unit 20 may 
again be activated after reconfiguration to execute step 
S32 for determination of mobile devices which are reachable 
from a reconfigured network node after installation of new 
software and transition to the target software 
configuration. This step S32 is particularly useful when 
network nodes are mobile and roam during the 
reconfiguration process, so that the ad-hoc network 
topology changes. 

Fig. 6 shows a flowchart of operation for the 
reconfiguration commitment unit 14 shown in Fig. 2. The 
operation outlined in this flowchart is related to the 
operation after the first phase to prepare the transition 
to the target software configuration or, in other words, 
after expiration of the timer provided in each network node 
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to compare the actual reconfiguration time with the 
negotiated maximum negotiation time. 

As shown in Fig. 6, after expiration of the time period 
5 reserved for preparing the transition to the new software 
configuration, the reconfiguration commitment unit 14 will 
evaluate whether a reconfiguration result was received at 
all in a step.S40. If this is not the case/ the * 
reconfiguration commitment unit 14 will decide on fallback 
10 to initial software configuration in a step S42. 

Otherwise, the reconfiguration commitment unit 14 will 
determine whether at least one negative indication for a 
reconfiguration was generated during the reconfiguration. 
15 If this is true, the reconfirmation commitment will decide 
on fallback to initial software configuration according to 
step S420therwise, a decision to commit to the target 
software configuration will be taken in a step S46. 

20 The logic behind the decision mechanism shown in Fig. 6 is 
that the interrogation whether no reconfiguration was 
received in step S40 corresponds to a situation where a 
network node can no longer form part of the ad-hoc network, 
e.g., due to roaming and moving away of a mobile network 

25 node from the area of the ad-hoc network. Here, a 

commitment to a target software configuration which might 
only be suitable for network nodes in the ad-hoc network 
would no longer make sense. 

30 Further, the reason to decide on fallback when at least one 
negative indication of reconfiguration is indicated is to 
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guarantee interoperability and consistency also after 
reconfiguration . 

However^ in an alternative manner and depending on the 
5 number of network nodes participating in the 

reconfiguration and further the type of reconfiguration^ 
one cbuld also consider a modification of the scheme shown 
in Fig. 6. 

10 E.g., a statistical evaluation of the indicated 

reconfiguration results using thresholds for acceptable 
negative reconfiguration level is as well covered by the 
present invention - 

15 It should also be noted that the ad-hoc network may split 
into several groups, each of which will have a common state 
AOf software version, but not necessarily the same. E.g., in 
a first group, a network node may have to fall back, and 
therefore the complete group will execute a fallback to the 

20 initial software configuration. To the contrary, the other 
group may achieve successful reconfiguration for all 
related network nodes. 

Fig. 7 shows a first example of the application of the 
25 reconfiguration process according to the present invention. 

For the example shown in Fig, 7 it is assumed that network 
nodes are mobile devices participating in the 
reconfiguration process. The mobile devices are not roaming 
30 during reconfiguration. Further, it is assumed that the 
battery of the mobile device T7 is too low, and that 
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therefore this mobile device will not participate in the 
reconfiguration process. 

As shown in Fig. 1, mobile device Tl distributes the 
software according to the target software configuration for 
each of the mobile devices T2 to T6. Then, the 
reconfiguration for all mobile devices takes place, except 
for mobile device T7 . 

At the end of the time period t reserved for 
reconfiguration, the result of reconfiguration is as shown 
in the lower part of Fig. 7, While mobile devices T3, Tl, 
T4 to T6 execute the reconfiguration process successfully, 
a failure occurs at mobile device T2 subsequent to 
successful reconfiguration of the other mobile devices Tl, 
T3 to T6. The failure is indicated to mobile devices Tl, T3 
^to T6 using failure signaling, e.g., a failure signal or 
message. At point of time tQ+t, all participating mobile 
devices Tl to T6 will decide on fallback to the initial 
software version due to failure of the reconfiguration 
process at mobile devices T2 . Alternatively, the same 
decision may be taken already at receipt of the failure 
indication from mobile device T2 . 

Fig. 8 shows a second example of the application of the 
reconfiguration process according to the present invention. 
For the example shown in Fig. 8 it is assumed that 
different network nodes are mobile devices that may roam 
during the reconfiguration process. 
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As shown in Fig. 8, the reconfiguration process for mobile 
devices T2, T3, and T6 is executed successfully, while the 
reconfiguration process at mobile device T4 fails. In 
addition, shortly before end of the time period reserved 
for preparing the transition to the target software 
configuration, connectivity between mobile devices T2 and 
T4 is lost, splitting the initial ad-hoc network Tl to T6- 
into partial ad-hoc networks, Tl, T2, T5, and T3, T4, and 



T6. 



The reconfiguration process is successful for the first 
partial ad-hoc network Tl, T2, T5, and therefore the first 
partial ad-hoc network will commit to the target software 
configuration. To the contrary, the second partial ad-hoc 
15 network will execute a fallback to the initial software 

configuration due to failure of reconfiguration process in 
mobile device T4 . 
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While in Figs. 7 and 8 examples have been shown where 
communication is possible during the first time period of 
the reconfiguration for decision on commitment to the new 
software, an alternative would be that communication is 
fully interrupted during the reconfiguration process. In 
the latter case, the reconfiguration result indication 
25 related exchange of information would be postponed until 
expiry of the time period t reserved for software 
reconfiguration. . 
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While above the best mode of carrying out the present 
invention as well as further preferred embodiment thereof 
has been explained with respect to the drawing, it should 
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be emphasized that all related features explained with 
reference to the drawing may as well be combined 
differently to achieve additional variations and 
modifications of the present invention. 
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CLAIMS 



Method of reconfiguration for a network node in an ad- 
hoc network, comprising the steps: 

preparing a transition from an initial software 
configuration to a target software configuration; 

deciding on commitment to the target software 
configuration in view of a result of reconfiguration 
indicated through at least one further network node 
in the ad-hoc network. 

Method according to claim 1, characterized in that it 

further comprises a step of negotiating a maximum 
reconfiguration time period with at least one further 
network node before executing the transition from the 
initial software configuration to the target software 
configuration. 

Method according to claim 2, characterized in that the 
maximum reconfiguration time period is the maximum 
time for reconfiguration, indication of 
reconfiguration result, and executing a fallback to 
the initial software configuration for network nodes 
in the ad-hoc network participating in the 
reconfiguration process. 
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Method according to one of the claims 1 to 3, 
characterized izx tixa't it fuirther comprises a step of 
coordinating a start of reconfiguration at the network 
.node with a start of reconfiguration in at least one 
further network node. 

Method according to one of the claims 2 to 4, 
characterized in that it further comprises a step of 
starting a timer in the network node for measurement 
of actual reconfiguration time versus maximum 
reconfiguration time period. 

Method according to one of the claims 1 to 5, 
characterized in that it further comprises a step of 
determining network nodes being reachable from the 
reconfigured network node when ad-hoc network 
communication is interrupted during the transition 
from the initial software configuration to the target 
software configuration. 

Method according to one of the claims 1 to 6, 
characterized in that the step of committing to the 
target software configuration is taken when every 
result of reconfiguration received at the network node 
from a reachable further network node is evaluated to 
be positive. 

Method according to one of the claims 1 to 6, 
characterized in that it further comprises a step of 
falling back to the initial software configuration 
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when at least one result of reconfiguration received 
at the network node from a reachable further network 
node is evaluated to be negative. 

Method according to one of the claims 1 to 6, 
characterized In that it comprises a step of falling, 
back to the initial software configuration when no 
result of reconfiguration result is received at the 
network node until expiry of the maximum 
reconfiguration time period. 

Method according to one of the claims 1 to 9, 
characterized in that it further comprises a step of 
sending a positive reconfiguration result when the 
transition from the initial software configuration to 
the target software configuration is successful. 

Method according to claim 10, characterized In that 

the positive reconfiguration result is sent as 
positive signal or indicated through automatic set-up 
of network connectivity. 

Method according to claim 10 or 11, characterized In 
that the positive reconfiguration result is sent 
repeatedly - 

Method according to one of the claims 1' to 9, 
characterized In that it further comprises a step of 
sending a negative reconfiguration result when the 
transition from the initial software configuration to 
the target software configuration is not successful. 
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Method according to claim 13, characterized in that 
the negative reconfiguration result is sent as 
fallback signal. 

Method according to claim 13 or 14, characterized in 
that the negative reconfiguration result is sent 
repeatedly. 

Method according to one of the claims 13 to 15, 
characterized in that it further comprises a step of 
forwarding results of reconfiguration received from 
further network nodes to the ad-hoc network. 

Method according to one of the claims 1 to 16, 
characterized in that it further comprises a step of 
determining network nodes in the ad-hoc network 
executing reconfiguration. 

Method according to claim 11, characterized in that 
the step of determining network nodes in the ad-hoc 
network executing reconfiguration is based on at least 
one criteria selected from a group comprising: 

communication capability of network node; 
network connectivity; 
profile data of network node; 
movement pattern of network node; 
hardware status of network node; 
priority of network node; and 
group membership of network node. 
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Method according to claim 17 or 18, characterized in 
that the step of determining network nodes in the ad- 
hoc network executing reconfiguration is executed 
before start of reconfiguration. 

Method according to one of the claims 17 to 19, 
characterized in that the step of determining network 
nodes in the ad-hoc network executing reconfiguration 
is repeated during reconfiguration. 

Method according to one of the claims 1 to 20, 
characterized in that it further comprises a step of 
retrieving software for executing the transition from 
the initial software configuration to the target 
software configuration locally from a portable 
electronic device (IC/USIM) . 

Method according to one of the claims 1 to 21, 
characterized in that it further comprises a step of 
retrieving software for executing the transition from 
the initial software configuration to the target 
software configuration remotely via a mobile 
communication environment. 

Method according to claim 22, characterized in that It 
further comprises a step of selecting the mobile 
communication environment from a group comprising a 
mobile communication network, wireless local area 
network, personal area network, wireless infrared 
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communication network (IrDA), Bluetooth communication 
network. 

Method according to claim 22, characterized In that it 
further comprises a step of selecting the mobile 
communication network from a group comprising GSM, 
PDC, IMT 2000, PHS, IS-95. 

Method according to one of the claims 21 to 24, 
characterized In that it further comprises a step of 
pre-installing software for executing the transition 
from the initial software configuration to the target 
software configuration in the network node. 

Method according to one of the claims 21 to 25, 
characterized In that it further comprises. a step of 
selecting software for executing the transition from 
the initial software configuration to the target 
software configuration from a group comprising 
application software, communication software, 
operating system software, firmware. 

Method according to claim 2 6, characterized In that it 
further comprises a step of retrieving software for 
executing the transition from the initial software 
configuration to the target software configuration in 
combination with related control parameters - 

Method according to one of the claims 1 to 27, 
characterized In that software for executing the 
transition from the initial software configuration to 
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the target software configuration is network node 
specific. 

Method according . to one of the claims 1 to 28, 
characterized in that the network node is a mobile 
device or a stationary device. 

Network node for operation in an ad-hoc network, 
comprising: 

a software reconfiguration unit adapted to prepare a 
transition from an initial software configuration to 
target software configuration; 

a reconfiguration commitment unit adapted to decide o; 
commitment to the target software configuration in 
view of a result of reconfiguration indicated through 
at least one further network node in the ad-hoc 
network. 

Network node according to claim 30, characterized In 
that it further comprises a negotiating unit adapted 
to negotiate a maximum reconfiguration time period 
with the at least one further network node before 
executing the transition from the initial software 
configuration to the target software configuration. 

Network node according to claim 31, characterized In 
that the negotiation unit is adapted to negotiate the 
maximum reconfiguration time period as the maximum 
time for reconfiguration, indication of 
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33, 



reconfiguration result, and executing a fallback to 
the initial software configuration for network nodes 
in the ad-hoc network participating in the 
reconfiguration process. 

Network node according to one of the claims 30 to 32, 
charactBxrlzed in that it further comprises a 
reconfiguration coordination unit adapted to 
coordinate a start of reconfiguration at the network 
node with a start of reconfiguration in the at least 
one further network node. 

Network node according to one of the claims 31 or 33, 
dbaraatarizBd in that it further comprises a timer 
unit adapted to measure an actual reconfiguration time 
versus the maximum reconfiguration time period. 

35. Network node according to one of the claims 30 to 34, 
characterized in that it further comprises a 
connectivity unit adapted to determine network nodes 
being reachable from the reconfigured network node 
when ad-hoc network communication is interrupted 
during the transition from the initial software 
configuration to the target software configuration. 
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Network node according to one of the claims 30 to 34, 
characterized in that the reconfiguration commitment 
unit is adapted to commit to the target software 
configuration when every result of reconfiguration 
received at the network node from a reachable further 
network node is evaluated to be, positive. 
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Network node according to one of the claims 30 to 34, 
characterized In that the reconfiguration commitment 
unit is adapted to decide on falling back to the 
initial software configuration when at least one 
result of reconfiguration received at the network' node 
from a reachable further network node is evaluated to 
be negative. 

Network node according to one of the claims 30 to 34, 
characterized In that the reconfiguration commitment 
unit is adapted to decide on falling back to the 
initial software configuration when no result of 
reconfiguration result is received at the network node 
until expiry of the maximum reconfiguration time 
period. 

Network node according to one of the claims 30 to 38, 
characterized In that it further comprises a 
communication unit adapted to send a positive 
reconfiguration result when the transition from the 
initial software configuration to the target software 
configuration is successful. 

Network node according to claim 39, characterized In 
that the communication unit is adapted to send the 
positive reconfiguration result as positive signal or 
adapted to indicate the positive reconfiguration 
result through automatic set-up of network 
connectivity. 
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41. Network node according to claim 39 or 40^ 
characterized In that the communication unit is 
adapted to send the positive reconfiguration result 
repeatedly. 

5 

42. Network node according to one of the claims 30 to 38^ 
characterized In that it further comprises a 
communication unit adapted to send a negative 
reconfiguration result when the transition from the 

10 initial software configuration to the target software 

configuration is not successful. 

43. Network node according to claim 42, characterized in 
that communication unit is adapted to send the 

15 negative reconfiguration result as fallback signal, 

44. Network node according to claim 42 or 43, 
characterized in that communication unit is adapted to 
send the negative reconfiguration result repeatedly. 

20 

45. Network node according to one of the claims 39 to 44, 
characterized In that the communication unit is 
further adapted to forward results of reconfiguration 
received from further network nodes to the ad-hoc 

25 network, 

46. Network node according to one of the claims 30 to 45, 
characterized in that it further comprises a 
determination unit adapted to determine network nodes 

30 in the ad-hoc network executing reconfiguration. 
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Network node according to claim 46, cb^acterlzed In 
that the determination unit is adapted to determine 
network nodes in the ad-hoc network executing 
reconfiguration based on at least one criteria 
selected from a group comprising: 

communication capability of network node; 
network connectivity; 
profile data of network node; 
movement pattern of network node; 
hardware status of network node; 
priority of network node; and 
group membership of network node . . 

Network node according to claim 46 or 41, 
cbaracterized In that the determination unit is 
adapted to determine network nodes in the ad-hoc 
network executing reconfiguration before start of 
reconfiguration . 

Network node according to one of the claims 4 6 to 48, 
cbaracterlzBd in that the determination unit is 
adapted to determine network nodes in the ad-hoc 
network executing reconfiguration repeatedly during 
reconfiguration . 

Network node according to one of the claims 30 to 49, 
characterized in that it further comprises a software 
retrieval unit adapted to retrieve software for 
executing the transition from the initial software 



configuration to the target software configuration 
locally from a portable electronic device . 

Network node according to one of the claims 30 to 50, 
characterized in that the software retrieval unit is 
further adapted to retrieve software for executing the 
transition from the initial software configuration to 
the target software configuration remotely via a 
mobile communication environment. 

Network node according to claim 51 , characterized in 

that the. software retrieval unit is adapted to select 
the mobile communication environment from a group 
comprising a mobile communication network, wireless 
local area network, personal area network, wireless 
infrared communication network (IrDA), Bluetooth 
communication network. 

Network node according to claim 52, characterized in 
that the software retrieval- unit is further adapted to 
select the mobile communication network from a group 
comprising GSM, PDC, IMT 2000, PHS, IS-95. 

Network node according to one of the claims 4 9 to 53, 
characterized in that it further comprises a software 
storage unit adapted to store software for executing 
the transition from the initial software configuration 
to the target software configuration in the network 
node, the software being selected from a group 
comprising application software, communication 
software, operating system software, firmware. 
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Network node according to claim 54, characterized In 
that the software storage unit is further adapted to 
store software for executing the transition from the 
initial software configuration to the target software 
configuration in combination with related control 
parameters. 

Network node according to one of the claims 30 to 55, 
characterized In that it is a mobile device or a 
stationary device. 

A computer program product directly loadable into the 
internal memory of a network node of an ad-hoc 
network, comprising software code portions for 
performing the steps of one of the claims 1 to 29, 
when the product is run on a processor of the network 
node. 
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ABSTRACT 

To improve consistency of software update in an ad-hoc 
5 network, it is proposed to prepare a transition from an 
initial software configuration to a target software 
configuration in a first step (SIO) . Before deciding on 
commitment to the new software configuration, there is 
executed a step (S12) to evaluate at least one 

10 reconfiguration result achieved at a further mobile device 
in the ad-hoc network. On the basis of this further 
reconfiguration result it may be decided whether after 
commitment to the new software configuration consistency of 
software versions may be maintained within the ad-hoc 

15 network. If this is not the case, e.g., due to a failure of 
software update in one of the mobile devices, a fallback to 
the initial software configuration is executed. 

20 (Fig. 3) 
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